131. The method as defin&f m claim 130 wherein said server computer routes the 
download data using a standard local a&a petwork protocol 



REMARKS 



Applicants have cancelled claims 1-40 and have added new claims 41-131. Support for 
the added claims may be found in the Specification, and thus no new matter is introduced by the 
added claims. In addition, Applicants have amended the Specification to correct minor 
typographical errors and to introduce reference to the microfiche appendix submitted with this 
Preliminary Amendment. Applicants have also amended the Specification to indicate the proper 
chain of priority for this Continuation Application. Neither the microfiche appendix nor the 
amendments to the Specification introduces new matter. Accordingly, Applicants submit that 
pending claims 41-131 are allowable. 

Applicants have included a "version with markings to show changes made" with this 
Preliminary Amendment. For clarity, Applicants have included pages 2-17 of the Specification 
even though changes may not appear on every page. In the interest of space, Applicants have not 
included deleted pages 18-159 or claims 1-40. 

In the event the Examiner does not find the claims allowable, Applicants request that the 
Examiner contact the undersigned at (801) 536-6707 to set up an interview. 

Please charge any additional required fees to our Deposit Account No. 50-0581. 
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One Utah Center 

201 South Main Street, Suite 1800 
Post Office Box 45898 
Salt Lake City, Utah 84145-0898 
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2 Software Appendix* Thi s s pecification includes a s oftware source code appendix which 

3 include s the computer s ource code of one preferred embodiment of the invention. In other 



4 embodiments of the invention, the inventive concept may be implemented in other computer 

5 code, in dedicated electronic hardware, in a combination of these, or otherwi s e. Thi s s oftware 

6 appendix i s hereby incorporated in thi s application in its entirety and i s to be con s idered to be 

7 part of the di s clo s ure of thi s s pecification. 
8 

9 I. BACKGROUND OF THE INVENTION 

10 A. Field of th e Invention Related Applications. 

11 This application is a Continuation of United States Patent Application Serial Number 

12 09/746,438. filed December 20. 2000. which is a Continuation of United States Patent 

13 Application Serial Number 08/943.544, now United States Patent Number 6.205.473 Bl. filed 

14 October 3. 1997. 

15 B. Reference to Microfiche Appendix. A microfiche appendix, containing three 

16 microfiche and 150 total frames is filed herewith. The microfiche appendix includes the 

17 computer source code of one preferred embodiment of the invention. 

18 C. Field of the Invention. 

19 This invention relates to methods and systems for communications between computers 

20 and other digital information devices. More particularly, this invention relates to 

21 communications between computers making use of digital satellite communications channels and 

22 computer local area networks, to provide access to the Iinternet, to facilitate data and software 
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1 distribution, and/or to enhance the capabilities of intranet systems for computers with 

2 connections to local area networks. 

3 BD. Description of Related Art 

4 It is well established that computers can communicate across local or wide area networks. 

5 It is also well known that satellite receivers and transmitters can be used to transfer high volumes 

6 of digital data. Some efforts have been made to provide communication systems which can be 

7 used to transfer data between computer processors using a variety of communication mediums 

8 (see Moura et al., U.S. Patent No. 5,586,121). However, it is desirable to provide a high-speed, 

9 low-cost, satellite-based communication system which is designed to optimize the use of digital 

10 satellite systems for local area networks (LANs). Optimizing the use of the digital satellite 

1 1 channel is best accomplished through the use of asymmetrical communications between the 

12 computer server and the iateme tlnternet as opposed to symmetric communication, in which 

1 3 substantially the same data rates and the same media are used for both the transmit direction and 

14 the receive direction, and as opposed to communication systems which employ asymmetrical 

15 communication between the local area network and the server. Particularly, asymmetrical 

16 systems which-require upstream router hardware, "backbone" network hardware, or dial-up 

17 Iinternet service providers (ISPs) to create a "hybrid" asymmetrical local system with a 

1 8 symmetrical local area network. Since calls to the internet lnternet can efficiently be made at 

19 relatively low speeds, and since using digital satellites as a communication medium provides the 

20 capability of very high speed responses from the interne t lnternet . an asymmetric transmission 

21 from the mtemetlnternet across the digital satellite to the LAN server provides the greatest 

22 system efficiency. 
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1 The most common method of sending and receiving computer information today is a land 

2 line service (i.e., a switched service, a dedicated line, and/or an analog modem, each using 

3 telephone wire lines). However, such a system encounters many problems, including slow 

4 transmission speeds, high access costs, lack of available wire lines, and internet lnternet 

5 congestion. 

6 Satellite communication receivers are commonly used to create or supplement existing 

7 private wide area data and video networks. When used as an extension to a data network, these 

8 satellite links may interconnect local area networks. Satellite links can provide many advantages 

9 over land line service, including potentially high speed data transmission and wide availability. 

10 However, typical satellite links have required expensive hardware both to transmit and to receive 

1 1 data. The expense of the hardware has made the use of satellite communication channels 

12 generally unavailable to those who most need it. 

13 This invention addresses these issues by providing a method and system for providing the 

14 advantages of satellite communications for high volume download data packets and typically 

15 using a relatively low speed land line for the low volume upload data request packets. By 

16 capitalizing on the asymmetrical nature of interne tlnternet dataflow, this invention provides an 

17 efficient solution for LAN to satellite interne tlnternet communications. 

18 For general background material the reader is directed to U.S. Patent Nos. 5,095,480, 

19 5,379,296, 5,423,002, 5,488,412, 5,534,913, 5,539,736, 5,541,911, 5,541,927, 5,555,244, 

20 5,583,997, 5,586,121, 5,594,872, 5,610,910, 5,610,920, 5,631,907, 5,659^92, 5,668,857, 

21 5,673,265, each of which is hereby incorporated by reference in its entirety for the material 

22 disclosed therein. 

23 IL SUMMARY OF THE INVENTION 
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1 This invention is a method and system for efficiently communicating between networked 

2 computers using a high speed satellite communications channel. It is an object of this invention 

3 to provide a high speed satellite based information delivery system for local area network 

4 connectivity to the internet lnternet . for file, data, software, and/or multimedia distribution. 

5 It is a further object of this invention to provide a data transmission system particularly 

6 well suited to remote location and/or locations where access to high speed data mediums is 

7 unavailable or prohibitively expensive. 

8 It is a further object of this invention to provide a high speed data transmission system 

9 that utilizes a highly flexible and adaptable software method. 

10 It is a further object of this invention to provide a high speed data transmission system 

1 1 that communicates with the intemet lnternet while being intemet lnternet service provider (ISP) 

12 independent. 

13 It is a further object of this invention to provide a high speed data transmission system 

14 that makes use of digital satellite communications technology to enhance data bandwidth, 

1 5 channel reliability, and accessibility. 

16 It is a further object of this invention to provide a high speed data transmission system 

17 that utilizes a software method capable of operating on a wide range of server operating systems, 

18 including Windows 95, Windows NT, NetWare, Linus, Macintosh, present and future versions 

1 9 and the equivalents. 

20 It is a still further object of this invention to provide a high speed data transmission 

21 system that is compatible with a wide range of communication protocols and/or mediums, 

22 including ISDN, Tl, modem, dedicated phone line, switched phone line, frame relay and ATM. 
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1 It is another object of this invention to provide a method for permitting many client 

2 computer systems, which may be operating system independent and operating on one or more 

3 local area networks, to communicate over a single satellite dish, at very high data rates. 

4 It is a further object of this invention to provide a method using software which can 

5 operate on a wide variety of hardware, operating system, and software platforms, including, but 

6 not limited to: Macintosh, Linux, Unix, OS/2, and Windows NT. 

7 These and other objects of this invention are readily apparent to individuals of ordinary 



8 skill in the art upon further study of the drawings, detailed description, claims and abstract that 

9 are included in this patent disclosure. 

1 0 III. BRIEF DESCRIPTION OF THE DRAWINGS 



1 1 Figure 1 depicts a top level rendering of the major component parts of the communication 

12 system invention. 

13 Figure 2 depicts a preferred embodiment of the architecture of the invention. 

14 Figure 3 depicts the preferred flow of data through the several protocol transitions in a 

1 5 preferred embodiment of the invention. 

16 Figure 4 depicts a top level flow diagram showing the primary steps of the process flow 

17 for an example single received data packet in the preferred method of the invention. 

18 Figure 5 depicts a detailed flow diagram showing the package delivery major step of the 

19 preferred embodiment of the invention. 

20 Figure 6 depicts a detailed flow diagram showing the iftteme tlnternet protocol (IP) major 

21 step of the preferred embodiment of the invention. 

22 Figure 7 depicts a top level flow diagram showing the primary steps of the process flow 

23 for an example transmission of internet lnternet protocol datagrams. 
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1 Figure 8 depicts additional detail showing the transfer queue (TxQ) thread processing of 

2 the filter queue step of the transmission portion of the invention. 

3 Figure 9 depicts additional detail showing new queue (NewQ) thread processing of the 

4 filter queue step of the transmission portion of the invention. 

5 Figure 10 provides an example embodiment of the user interface of the invention. 

6 IV. DETAILED DESCRIPTION OF THE INVENTION 

7 This invention is a system and method for asymmetric communications? between a 

8 remote information provider and a client computer system residing on a local area network 

9 (LAN), using high bandwidth digital satellite communication channels. The preferred 

10 embodiment of the method of the invention is performed in software residing on a local 

1 1 computer system. The current preferred embodiment of the method software ie-i^written in Intel 

12 386 assembly code, C and C++ computer languages. The reader is directed to the appended 

13 computer software microfiche appendix for a complete disclosure of the software making up the 

14 current best mode of the method of this invention. Alternatively, those of ordinary skill in the art 

1 5 could practice this method in a wide variety of procedures, computer languages, or even in 

16 dedicated electronic hardware. Therefore this patent should not be read to be limited to the 

17 specific embodiment of the provided software microfiche appendix. Rather, this software source 

18 code is provided to fully describe one preferred embodiment of the method of this invention. 

19 Also, in its preferred embodiment, this invention performs in association with DirectPC satellite 

20 receivers, Novell NetWare network software, and standard off-the-shelf computer hardware. 

21 Other alternative satellite receiver systems, networking software and computer hardware could 

22 easily be substituted by those of ordinary skill in the art without departing from the essence of 

23 this invention. Similarly, the preferred embodiment, described in the following detailed 
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1 description, includes a number of components and method steps which may not be absolutely 

2 necessary in other embodiments of the invention. The reader is, therefore, directed to the claims 

3 for a description of the range of this patent. 

4 Figure 1 depicts a top level rendering of the major components and communication paths 

5 constituting the system 100 of this invention. A client computer lOla-g is shown clustered with 

6 other client computers on a local area network (LAN) 102. The client computer 101 uses 

7 standard off-the-shelf commercially available software, while the server provides the user 

8 interface to the desired information. The LAN 102 provides the means for communicating from 

9 the client computer 101 to a server 103, which provides the communication interface outside the 

10 LAN. The server 103 receives data from a digital satellite receiver 110, depicted here as a 

1 1 satellite dish, across a signal antenna waveguide 115. The digital satellite receiver 110 receives 

12 the digital information from a downlink channel 111, which is transmitted from a 

13 geosynchronous satellite 112. The satellite 112 receives the information from a network 

14 operations center 1 14 via an uplink channel 113. The server 103 generally uses the above 

1 5 described communications channel from the network operations center 1 14 for downloads of 

16 information, such as internet lnternet web page data, software updates, data file distributions and 

1 7 other similar data packages. Alternatively and in addition, this invention provides the capability 

18 of using another satellite communication channel to send requests from the client computer 101 

19 to the network operations center 114. This is a particularly useful feature for access from remote 

20 locations. Use of the satellite communication channel provides important benefits to the 

21 information requestor at the client computer 101, including very high speed data transfer, the 

22 ability to receive broadcast software distributions which in turn means the requestor is likely to 

23 receive such distributions in a more timely and cost effective manner, and the ability to have 
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1 internet lntcrnet access from locations where wired communications channels, such as telephone 

2 lines, are either unavailable, overly burdened, or prohibitively expensive. 

3 Figure 1 also shows the preferred, and more typical request communications channel. In 

4 this preferred request channel the client computer 101, connected through the LAN 102, through 

5 the server 103, sends a request via modem 105, which typically is connected to the server via a 

6 standard serial RS-232 cable 104. The modem 105 in turn is connected to standard telephone 

7 land lines 107 via a standard phone cable 106. The request is passed across the land lines 107 to 

8 the interaet lnternet service provider 108, which communicates to the internet lnternet 109. 

9 This invention is designed to be highly flexible and adaptable to different client computer 

10 101 configurations, both hardware and software as well as with and to a wide variety of 

1 1 communication interfaces. Computer hardware such as personal computers, workstations, mini 

12 computers, mainframe computers and special purpose computational equipment can be 

13 functional client computers 101 as intended within this patent specification. Similarly, computer 

14 system operating systems which are supported and used in the preferred and alternative 

15 embodiments of this invention included but are not limited to: Windows 3.1, Windows 95, 

16 Windows NT, Macintosh, Linux, Unix, OS/2, NetWare, their current versions, past versions, and 

17 equivalent future versions and the equivalent. Communications interfaces that are or can 

1 8 alternatively be used with or as a part of this invention include routers, ethernet, ISDN 

19 equipment, switched 56, Tl, Token Ring, frame relay, modems, satellite and the equivalent. 

20 The advantage of this preferred mode of operation is that the communication channels are 

21 used in the most efficient manner. Typically, request packets are relatively small and can be 

22 transferred with minimal impact across land lines. While downloaded packets can be very large 

23 with significant amounts of highly concentrated graphics. For the vast majority of client 
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1 computer 101 users the limitation of the Ii nternet or the ability to receive other downloaded file 

2 information is the time it takes for the download transfer to be accomplished. This problem is 

3 solved by transferring the potentially very large downloaded packets (files, graphics, and other 

4 information) using the high bandwidth satellite channel. 

5 Figure 2 depicts a preferred embodiment of the software architecture of the invention. As 

6 shown, in its preferred embodiment, this software operates in association with several standard 

7 commercially available software packages and protocols, including Novell NetWare, Ethernet, 

8 Token Ring, TCP/IP, IPX and AIO. This software method of the invention also makes use of 

9 certain commercially available hardware component!, as shown in figure 2, including: the 

10 satellite receiver 1 10, a network router 205 and a modem 104. The reader should understand that 

1 1 this figure 2 presents a single simplified embodiment of the invention. Alternative embodiments 

12 could use alternative software packages and protocols, as well as different or multiple hardware 

13 components. Figure 2 also shows a single embodiment of the path of information through the 

14 various software and hardware components. Download information packets are received by the 

1 5 satellite receiver 110, which in turn communicates electronically with the DPC LAN 210, a 

16 commercially available hardware driver. The information next passes through the LSL NLM 

17 202, a routine commercially provided by Novell Incorporated which acts as an intermediary 

18 between the driver and the protocol stack to control information packet transfer. Next, the 

19 TCP/IP 203 protocol stack receives the information packet. The TCP/IP 203 protocol stack is 

20 capable of communicating alternatively with a modem 104, via the LSL NLM 202; the 

21 DPC AGENT 207 routine, core to this invention; the AIO 208, a Novell product for managing 

22 serial communications; and through the AIOCOMX 209, which is the asynchronous 

23 input/output interface to the client computer hardware communication ports, or with router 205, 



414548.1 




1 via the LSL NLM 202, the DPCAGENT 207, the LSL NLM 202 and an ethernet driver 204. 

2 Alternative embodiments of this invention may make use of other standard commercially 

3 available communication protocols, drivers, hardware and software. 

4 Figure 3 depicts the flow of information in the preferred embodiment of the invention 

5 from the satellite 1 12 to the client computer 101 as well as the flow of information back to the 

6 interaet lnternet 109 from the client computer 101. Data is received 301 from the satellite 1 12 by 

7 the satellite receiver 10. Next, the data is transmitted to and received by the server 103 hardware 

8 302 where it is placed in on-board memory. The DPC.LAN DirecPC network card driver 

9 retrieves the data packet from hardware memory 303. Next, if the packet is identified as an 

10 internet lnternet protocol (IP) format packet it is delivered to the IP protocol stack 304. If the 

1 1 packet is identified as a transmission control protocol (TCP) segment, it is delivered to the TCP 

12 protocol stack 305. TCP delivers the data packet to a proxy gateway 306. The proxy gateway 

13 forwards the data packet to the client computer via the local area network and standard LAN 

14 protocol controllers 307. Next, the client computer processes the data and generates a return 

15 packet 308. The return packet is delivered to the proxy gateway via the local area network and 

16 the standard LAN protocol controllers 309. The return packet is forwarded to the TCP stack 310, 

1 7 and next to the IP stack 311. The EP delivers the return packet to the DPCAGENT.NLM process 

18 312, which delivers the return packet data to a transmit device, such as a modem or a router 313. 

19 Figure 4 depicts a top level flow chart rendering of the major steps of the process flow for 

20 a single downloaded data packet section of the invention. Initially the downloaded packet is 

21 received 410 by the DirecPC circuit card. This circuit card next transfers the packet data to the 

22 DPC.LAN routine 402. In the preferred embodiment of the invention, as shown in the source 

23 code appendix, the DPC.LAN routine is denoted as DriverlSR proc. This process includes the 
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1 steps of setting up the RAM adapters and establishing a timestamp for the packet. Further 

2 detailed information on the functioning of this routine is found within the software microfiche 

3 appendix. Next, a test is made 403 as to whether the received data is a package delivery or an 

4 internet lnternet delivery. If the received data is package data, it is delivered 404. Package data 

5 delivery includes and provides the capabilities of simultaneously broadcasting software upgrades 

6 or data files to many client computers, potentially throughout any one continent. Client 

7 computers can also request the package data delivery service to retrieve a package of information 

8 through the client accessible interface of the invention. If the received data is mteme tlnternet 

9 data, then interne tlnternet data delivery is made 405. Additional detail on steps 404 and 405 

10 follows in this specification. 

1 1 Figure 5 depicts a detailed flow chart of the preferred embodiment of the package 

12 delivery major step of the method of the invention. The data packet is transferred to the 

13 DPCAGENT.NLM process 501. This process is a NetWare Loadable Module (NLM) process 

14 running on NetWare. After the data packet is received 501, a test is made to determine whether 

15 the packet will update the catalog 502. If the catalog will be updated, then it is updated 503 

16 using off-the-shelf commercially available software and the process of package delivery for that 

1 7 packet ends 511. If, however, the catalog will not be updated, then a test is performed to 

18 determine whether the site will be updated by the data packet 504. Site updates include 

19 modification of such site parameters as NOC versioning, encryption key updates, and becoming 

20 a member of a group or leaving a group. If the site will be upgraded, then the process performs 

21 the upgrade of the site parameters 505, and the process for this packet ends 511. If the site will 

22 not be updated, then the package file is found and stored on the server disk 506. A test is then 

23 made to determine whether the end-of-file has been encountered 507. If the end-of-file has not 
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1 been encountered then the process for that packet ends 511. However, if the end-of-file has been 

2 encountered, then a test is made to determine whether there are any "holes" in the file, that is 

3 whether the file is incomplete 508. If no holes are found in the file, it is marked as complete 509 

4 and the process for this packet ends 511. If "holes" are found in the file, then a request for 

5 partial retransmit of the missing packet is sent 510, at which point the process for this packet 

6 ends 511. 

7 Figure 6 depicts a detailed flow chart of the preferred embodiment of the internet lnternet 

8 protocol delivery major step of the method of the invention. Internet package delivery OR 

9 Internet Protocol (IP) delivery is a major function of the invention providing the capability of 

10 receiving large files from an internet Internet source at a very high speed. First the data packet is 

1 1 transferred to the DPCAGENT.NLM routine 601 . A test is made to determine whether the data 

12 is in transmission control protocol (TCP) 602. If the data is not in TCP protocol then the data 

13 packet is transferred to the Internet Protocol (IP) stack 609 and the process for this data packet 

14 ends 610. If the data is in TCP form then a test is made to determine if a "SYN" or beginning of 

15 section is being initiated 603. If no "SYN" is detected, then a test is made to determine if an end 

16 of session, commonly a FIN or RST command, has been encountered 605. If no such end of 

17 session is found, then the data packet is transferred to the EP stack 609 and the process for this 

18 packet is ended 610. If, however, a "SYN" is detected, then the inquiry is made as to whether a 

19 connection slot is available 604. Connection slots perform the function of managing the number 

20 of subscribers permitted to have access to the communication network at a given time. If a 

21 connection slot is available, it means that the customer still has client computer access capacity. 

22 If a connection slot is available, a connection slot is allocated 607 and the data packet is 

23 transferred to the IP stack 609 and the process ends. If it is determined that a connection slot is 
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1 not available, then the data packet is dropped or discarded 606 and the process for this packet 

2 ends 610. 

3 Figure 7 depicts a top level flow chart showing the primary steps of the preferred 

4 embodiment of the transmission of internet lnternet protocol datagrams (or packets) method steps 

5 of the invention. Packets that are received from the IP stack are stored on the NewQ 701. Next 

6 the packet is removed from the NewQ and tested against the-each and every packet on the TxQ 

7 to determine if any TxQ data is redundant or dated and should be replaced 702. If a comparison 

8 of the packet with the TxQ packets finds the updated or "newer" information, then the TxQ 

9 packet data is replaced by the current packet data. This approach is essential to maintaining the 

10 fairness of the TxQ packet transfers while ensuring that good data is transmitted thereby 

1 1 improving the transmission efficiency of the system. A test is performed to determine if the 

12 packet was included in the TxQ 703. If the packet was not included then the current or NewQ 

1 3 head packet is dropped or discarded 704. Otherwise, if the packet was included, a test is 

14 performed to determine if the NewQ is empty 705. If the NewQ is not empty, the process returns 

15 to the test NewQ step where a new NewQ head packet is compared against the TxQ. If, 

16 however, the NewQ is empty, then the process enters a wait state 706 where a trigger* that is 

17 meeting a specified condition, such as new packet on the NewQ or exit command, is required 

1 8 before the process restarts at the testing step 702. 

19 Figure 8 depicts a detailed flow chart showing the transfer queue (TxQ) thread processing 

20 steps of the transmission portion of the invention. In the preferred embodiment of the invention 

21 processing the TxQ and processing the NewQ are independent threads of the program which are 

22 capable of running independently on one or more computer processors. In processing the TxQ it 

23 is first determined whether the TxQ is empty 801 . If the TxQ is empty, then the process enters a 
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1 wait state 805 where a trigger, such as a polling timer, a transmission complete signal, or an exit 

2 command, is required to resume processing. Note that in the preferred embodiment of the 

3 invention the expected wait time is calculated in this step and the polling time is initiated. If the 

4 TxQ is not empty, a test is made to determine if the head packet of TxQ is too old 802. In the 

5 preferred embodiment of the invention, too old is defined as a packet that has been in the TxQ 

6 for more than sixty (60) seconds. Alternative embodiments could employ any practicable time 

7 period. If the TxQ head packet is too old, then it is discarded 806 and the process returns to the 

8 TxQ empty test 801. If the TxQ head packet is not too old, then a test is made to determine if the 

9 media, or communication conduit, is capable of transferring another packet of data 803. If the 

10 media is capable of transferring another packet, then the packet is written to the transmission 

1 1 device 804, otherwise, the process enters the wait state 805 and waits for a trigger as described 

12 above. 

13 Figure 9 depicts a detailed flow chart showing the new queue (NewQ) thread processing 

14 steps of the filter queue step of the transmission portion of the invention. The filter queue 

15 processing step of the invention, which is the core of step 702, is important in providing the 

16 communication efficiency which is one of the key objectives of this invention. A test is made to 

17 determine whether the NewQ is empty 901 . If the NewQ is empty then a wait state is entered 

18 902 where a trigger, such as new packet available in NewQ, exit or timer count, is required to 

19 resume the process. If NewQ is not empty, then the head of NewQ is renamed as ECB 903, a 

20 packet holding variable. The maximum age of the ECB packet is set 904 and a test is performed 

21 to determine if the ECB packet is fragmented 905, that is whether ECB is only a partial packet, 

22 which in the current best mode of the invention is not inspected. If ECB is fragmented, then it is 

23 appended 906 to the TxQ for transmission. If ECB is not fragmented, then a test is performed to 
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1 determine if it is a TCP packet 907. If it is not a TCP packet, then the test is made to determine 

2 if it is a UDP packet 980. If it is not a UDP packet or a TCP packet then it is appended to the 

3 TxQ for transmission 906. If, however, it is a UDP packet, a test is made to determine if ECB is 

4 a duplicate of a DNS request 909. If ECB is not a duplicate of a DNS request, then the packet is 

5 appended to TxQ 906. If ECB is a duplicate of the DNS request, then it is discarded 910 and the 

6 process returns to testing to see if NewQ is empty 901. If it is a TCP packet, then a test is made 

7 to determine if ECB is a "SYN" or beginning of session packet 911. If ECB is a "SYN" packet, 

8 then a test of whether a connection slot is available is made 912. If a connection slot is available 

9 it is allocated 913. If, however, a connection slot is unavailable ECB is discarded 910. If ECB is 

10 not a "SYN" packet then the test is made to determine if ECB is a session abort packet (RST) 

1 1 914. If ECB is found to be a session abort packet TxQ is cleared of all matching packets 915 and 

12 a test is made to determine if ECB will terminate a session 916. If ECB is not a session abort 

13 then the step of clearing all matching packets 915 is skipped. If the ECB is found to terminate a 

14 session, then the connection slot is released 917. A test is then performed to determine if ECB is 

15 void of user data 918. If it contains user data then it is appended to TxQ 906. Otherwise, the 

16 End-of- Window-Position (EOWP) is computed 919 and a test is made to determine if ECB' s 

17 EOWP is greater than the matched TxQ packets 920, if not ECB is discarded 910, and if so, ECB 

18 has its EOWP stored in matched TxQ 921 and then ECB is discarded 910. 

19 Figures 10a-k4- show various screen shots demonstrating the user interface of the 

20 invention. Figure 10a shows the DPC AGENT routine options for user selection as well as the 

21 digital package delivery queue screen. Figure 10b shows a package of data in transit as 

22 displayed on the user screen. Figure 10c shows the main screen of the package delivery 

23 interface. Figure lOd shows package statistics as displayed for user information. Figure lOe 
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1 shows configuration control screens where the user can modify certain modem, package delivery 

2 and provider configuration information. Figure 1 Of shows the package delivery configuration 

3 editor screens with the information that can be user modified. Figure lOg shows the login script 

4 editor and the provider configuration editor. Figure lOh shows additional provider configuration 

5 editor screens showing the configuration of an outbound protocol case. Figure lOi shows the 

6 dish or antenna pointing adjustments screens. Figure lOj shows the satellite dish signal strength 

7 meter for dish alignment. Figure 10k shows the adapter information screen, here showing site 

8 information including the card hardware serial number, the site identification, the status of keys, 

9 and a list of communities or groups in which the user is participating. 
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